28章 コンストラクションの管理
tommy.icon
コンストラクションに直接関連する部分
開発者であれば、PMに検討させなければならない問題を理解するのに役立つ
28.1 良いコーディングの奨励
プログラミングの標準は一目置かれているアーキテクトに定義させる
「一目置かれている」ってぼんやりしているな tommy.icon
28.1.1 標準を設定するときの検討事項
効果は組織による
28.1.2 良いコーディングを奨励するテクニック
2人で分担
1行ずつコードレビュー
一般に、コードレビューはプログラマと2人のレビューアで行われる
そうなのか tommy.icon
「ピアプレッシャー」
決定がコーディング標準となっていく
コードのサインを要求
これやれてないなぁ tommy.icon
良いサンプルコードに基づいたレビュー
良いかも tommy.icon
コードが共有資産であることの強調
例のプロジェクトなんなんだろうかと気になる tommy.icon
良いコードを称える
これ良さそう tommy.icon
1つの簡単な標準を決める
良し悪しはプロジェクトマネージャーの力量によりそう tommy.icon
28.1.3 本書の役割
本書はたたき台
28.2 構成管理
28.2.1 構成管理とは
SCM
Version Control Systemとはまた違う文脈なのかな tommy.icon
書かれていることはVCSっぽいがイマイチ違いがよく解らなかった tommy.icon
28.2.2 要求と設計の変更
体系的な変更管理手順に従う
変更要求をまとめて処理
アイデアと提案を書き留めておくの良さそう tommy.icon
レビューでリリース優先なのであとでいいですと指摘しても放置されがち tommy.icon
各変更のコストを見積もる
見積もりめっちゃムズいんだよなぁ tommy.icon
大量の変更に注意
アーキテクチャ、上位レベルの設計を見直す
変更管理委員会のやそれに相当するグループを設ける
これは大規模な組織じゃないと無理そう tommy.icon
効果的な変更管理を妨げない程度に体制的に監視する
運用難しそう tommy.icon
28.2.3 ソフトウェアのコードの変更
今のGit全盛の時代とはちょっと離れてそう tommy.icon
28.2.4 ツールのバージョン
これはやろうと思えばやれそう tommy.icon
28.2.5 マシンの構成
Dockerの時代にこれはちょい時代遅れかも tommy.icon
28.2.6 バックアップ計画
バックアップが標準機能化されている今だとここも時代遅れ感ある tommy.icon
28.2.7 構成管理の参考文献
そもそもSCMっていう言葉を聞かない気がするけど気のせいか tommy.icon
28.3 コンストラクションスケジュールの見積もり
見積もり誤りがちという話
28.3.1 見積もりの方法
目標を立てる
何を見積もっているのか
どれくらい確実にしなければいけないか
見積もりを作成し、計画を立てるための時間を設ける
見積もり自体をミニプロジェクトにする
ソフトウェアの要求をすべて洗い出す
下位レベルの詳細を見積もる
大数の法則
何種類かの方法で見積もり比較する
250〜300ページの見積もりが873ページってすごいなw tommy.icon
どういう方法で見積もりをしたか書いてほしかった tommy.icon
定期的に見積もりを見直す
28.3.2 コンストラクションの作業量の見積もり
コンストラクションの必要加減はプロジェクトごと、組織ごとに異なる
28.3.3 スケジュールへの影響
列挙されてるだけであまり参考にならない感が tommy.icon
28.3.4 見積もりとコントロール
最初の見積もりの正確さよりもスケジュールに合わせた資源のコントロールのほうがはるかに重要
予測したいか、コントロールしたいのか、それが重要だ。
28.3.5 遅れたらどうするか
遅れを取り戻せることを祈る
いきなりこれかw tommy.icon
チームを増強する
タスク分割されていればその限りではない
プロジェクトの範囲を狭める
必須、あるとよい、任意への分類
これは大事そう tommy.icon
28.3.6 ソフトウェアの見積もりに関する参考文献
28.4 測定
プロジェクトのどの特徴も、まったく測定しないよりはいい方法で測定できる
数字による裏付けが必要
測定の副作用に注意
測れるものは達成される。
測定に反対することは、プロジェクトに実際に何が起きているのかを知らないほうがよいと言っているようなもの
28.4.1 ソフトウェアの測定に関する参考文献
「測定」というのが何を指しているのかイマイチぴんと来なかった tommy.icon
工数？実行効率？
28.5 プログラマは人間である
28.5.1 プログラマは時間をどのように使うか
これ測定たいへんだったろうな tommy.icon
リモートワークだとまた違ったデータが出そう tommy.icon
28.5.2 パフォーマンスと品質のばらつき
上位20%が全体の約50%の成果をあげる
個人差
パフォーマンスの比率には意味がなく、プログラマによって大きな差が出ることに意味がある
チーム差
良いプログラマは群れをなす
28.5.3 信仰の問題
「提案」や「ガイドライン」を使用する
厳格な「規則」や「標準」を設けない
28.5.4 物理的な環境
環境大事
28.5.5 プログラマが人間であることに関する参考文献
ピープルウェアは読んでみたい本の一つ tommy.icon
28.6 管理者の管理
階層社会の中では、どの社員も無能レベルを上げていく。
自分の仕事の「カプセル化」っていいな tommy.icon
良い本だなと思いつつ途中まで読んで放置してある… tommy.icon
28.7 参考文献
人月の神話、1975年初版なのに今（当時）でも新鮮っていいな。いつか読もう tommy.icon
28.8 まとめ